cc @m-e-h . Apologies, I had meant to mark you as co-author since your debugging at #14817 (comment) was very accurate in leading to the underlying cause. I'd welcome your feedback if you have any.

I'm seeing a small issue, where if I "hover" an unselected wide image, horizontal scrollbars appear. I don't know if this is specific to this PR yet but I don't see this as critical to fix (compared to the issue fixed by the PR itself)

(The hover issue is specific to this branch)

There was a regression with the toolbar on all wide blocks, it wasn't centered whereas it was in 4.7. This meant the movers weren't accessible on wide alignments. Fix pushed. Debugging with Andrew for the hover issue, and have some clues.

Fixed the two issues that regressed -- sorry about that. The toolbar is centered on wide, so on the right breakpoints the movers are present again. And they are clickable, there was an inherit that targetted a rule no longer there. Thanks all.

I think this needs @kjellr input. Btw with the mover above, I think we could do with the hover label on the left again.

I restored the left-alignment in a combination of 93bdae6 (revert) and c2086aa (the "corrected" descendent selector interfered with the intended alignment of the hover label).

While I'd previously remarked about the potential for conflict here (#14145 (comment)), I think this is better due to:

• The mover z-index was corrected to appear higher, so it is operable unlike as indicated in Try using left borders for hover + selection states #14145 (comment)
• The mover is accessible while the block is selected
• The hover label seems to be designed as assuming the left-border hover state of the block, and appears incorrect if the hover label were right-aligned (with the left border still present)
• It should fix the issue noted by @youknowriad at Block Editor: Restore block movers to full-, wide-align blocks #15022 (comment) without further consideration of the ideal right value

The last commit 2b2e556 resolves my final uncertainty here by restoring descendent styling to multi-selections, since the descendent hierarchy differs between singular and multi-selections. Without these changes, a multi-selection which starts with a wide- or full-align block would still not show movers.

For all of the above, I would still recommend we explore in the future ways to consolidate these differences in markup / hierarchy, but this should be sufficient for resolving the immediate bug.

I think if we add e2e tests to move wide aligned and full-width aligned blocks we potentially guard against the two regressions seen here. (which I think is not the first time we see them regressing).

(Good as a follow-up though)

I'd accidentally left my merge settings as "Rebase and Merge" from a previous release, so the individual commits were merged rather than as a single unit. I will cherry-pick each individual commit into #15020 to retain this.

Sorry for coming into this late: I just want to follow up and check what I should be expecting to see here post-merge. When testing on my local install, I'm seeing the block movers return to wide and full-width blocks:

I'm seeing overlap between the block label and the movers on hover. (As @aduth noted over in #14145 (comment), the placement of those labels seemed fine when the movers were mistakenly missing, but isn't great now). Is that what I should expect to see here? If so, I'll open a new PR to try addressing that.

Thanks for checking in, @kjellr . All of what you mentioned is expected, yes.

I'd acknowledge and agree that the overlap is not great, but it is operable enough in my opinion to have been the best compromise to resolving the bug while respecting design for the immediate need of the WordPress 5.2 RC. Follow-up improvements would be welcomed, though it'd be my expectation that these would not be present for WordPress 5.2.